VIRTUAL TELEPHONE 



BACKGROUND OF THE INVENTION 

1. Field of the invention 

The present invention relates generally to a 
telephone communication system and, in particular, to a 
device that provides a generic software interface to a 
digital line on one of many different types of digital 
phone switches. A telephone with such a generic 
interface is a ""virtual phone" that has the flexibility 
to represent the majority of features of any digital 
phone, regardless of the switch type or the number of 
features in a digital phone. 

The general concept of a virtual telephone has been 
in existence in various forms across different product 
lines. In some cases a virtual phone has been used to 
represent a specific digital phone, such as Rolm Phone 
400 or a Meridian 2616. Those phones represent a 
superset of phones for their respective switches. In 
other cases a virtual phone has been used to represent 
only the necessary portions, or a subset, or a digital 
telephone . 

J 

2. Prior Art 

One of the important characteristics of a 
telecommunication system is the ability of different 
interconnected components of the system to effectively 
communicate with each other. Many business-oriented 
telecommunication systems have PBX (Private Branch 
Exchange) switches that link internal telephones with 
each other and with external telephone networks. 
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Even though today most vendors build the PBXs 
around common available processors running common 
operating systems (such as UNIX) and use common 
programming languages (such as C or C++), unfortunately 
5 different vendors' switching devices use proprietary 
communication protocols. Thus, it is virtually 
impossible to integrate one vendor' s switching device 
with other vendors' applications. 

10 Therefore, it becomes highly desirable to provide a 

telecommunication system with a feature that would 
convert proprietary PBX or external application 
protocols into a common format, and thus would function 
as a ""protocol interpreter" between proprietary 

15 switching system protocols and the protocols of various 
applications . 

A number of solutions to that problem have been 
disclosed in the prior art. For example, U.S. Patent^ 
20 No. 4, 873, 718 * Feature Telephone Integration Device" 
issued to Barnett et al discloses a device and method 
for integrating one vendor's application (a voice mail 
system) into a PBX environment of a different vendor. 
In that patent the interconnection was achieved by 
25 equipping the PBX vendor's feature phone with additional 
circuitry to monitor telephone communication between the 
PBX, the feature telephone and the external application. 
An obvious disadvantage of the disclosed system is its 
inability to provide a generic interface between many 
30 possible proprietary protocols of different PBX 

switching systems and an external application. The 
* disclosed invention provided integration only between a 
PBX and a voice mail system, it did not provide for the 
possibility to integrate a PBX with a variety of 
35 different external applications. Moreover, any exchange 



of information about a call or a change of the status of 
the call occurs * one-way" only: from the PBX to the 
telephone set. 

U.S. Patent No. 5,440,616 provides an improvement 
over the device of Patent No. 4,873,718 in the form of 
apparatus for interconnecting a messaging system (voice, 
facsimile, etc.) with a PBX which offers entirely 
digital transmission and provides high bandwidth and 
redundant transmission of control information between 
the messaging system and the PBX. The apparatus of 
Patent No. 5,440,616 includes a digital voice terminal 
adapter which is a combination of hardware and software 
which emulates a digital feature phone and which 
interconnects a messaging system and a PBX to provide 
full integration of the messaging system with the PBX. 
The disclosed adapter does not, however, convert 
proprietary/PBX or external application protocols into a 
common format and thus does not function as a protocol 
interpreter between proprietary switching system 
protocols and the protocols of various applications. 

U.S. Patent No. 5,255, 314 * Switch Adjunct 
Integration Device" issued to Applegate et al discloses 
a device that uses multiple line appearances of one or 
more digital telephone lines to gather information on 
calls designed for an adjunct voice mail system. After 
receiving the required information the device transfers 
the calls to analog phone lines leading to the voice 
mail system. That device, again, provides no more than 
a communication tool between a PBX switch and a voice 
mail system. The disclosed device does not integrate 
any type of the known PBX switches with any type of 
external device via a generic interface. 
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SUMMARY OF THE INVENTION 

Advantageously, the present invention overcomes the 
"protocol conversion" difficulties which existed in the 
5 prior art. The virtual phone generic interface of the 
present invention comprises three distinct modules: a 
virtual phone data structure, a program interface, and a 
host interface. All three modules can work 
independently of a specific type of integration. The 
10 data structure and the program interface software of the 
virtual phone are built into the embedded processor that 
controls the Private Branch Exchange (PBX) digital phone 
switching system interface integration. The interface 
between the switch and the virtual phone data structure 
is different for each integration, but once the 
interface is completed, it can be reused for many 
different types of applications. The interface between 
the virtual phone structures and the external 
application is the same regardless of the type of 
integration. 

The implementation of the virtual phone provides 
for an external interface through any type of transport 
medium. A phone application residing on an auxiliary PC 
can show the current status of the virtual phone, and 
can al so do call control. This illustrates the common 
external interface and also provides a method for 
diagnostics. The interface to the auxiliary PC is 
accomplished in different ways based on the system 
configuration. It can be done via a serial port, ISA 
bus, PCI bus, universal serial bus, Ethernet, or any 
other type of transport configurable. An internally 
designed protocol is used to communicate between the 
virtual phone and the auxiliary PC. In essence, the 
virtual phone acts as a protocol converter between the 
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proprietary switch messages and the external serial 
interface . 

The virtual phone of the present invention provides 
a common interface between any of the digital phone 
switches and any number of end devices. The virtual 
phone represents the current state of some theoretical 
phone and has buttons, lights, a hook switch, display, 
ringer, and anything else typical of a standard digital 
phone. The main component of the virtual phone is a set 
of structures that represent the state of the phone at 
any given time. The virtual phone structures can be 
accessed via a set of Virtual Phone Application Program 
Interface (VPAPI) function calls. The virtual phone 
status and events are transmitted externally via a 
custom virtual phone host interface. 

When a packet is received from a switch, an 
abstraction layer parses the data and calls an internal 
VPAPI function. The internal VPAPI function is 
responsible for updating the virtual phone structure and 
passing the information about any state changes to an 
auxiliary PC through the virtual phone host interface. 
An internally designed protocol is used to provide 
communication between the virtual phone and the 
auxiliary PC through the host interface such as a 
standard RS232 communications port. A phone application 
residing on the auxiliary PC can show the current status 
of the virtual phone and accomplish call control tasks. 
So, in essence, the virtual phone functions as a 
"protocol interpreter" between the proprietary switch 
messages and the external interface. 



When an event is received from the auxiliary PC, an 
external VPAPI function is called to update the virtual 
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phone. The event is passed to an abstraction layer 
where it is converted to a command format in accordance 
with a specific virtual phone integration. The command 
is then subsequently passed to the switch. 

The foregoing and additional advantages and 
characterizing features of the present invention will 
become clearly apparent upon a reading of the ensuing 
detailed description together with the included drawing 
wherein : 

BRIEF DESCRIPTION OF THE DRAWING FIGURES 

Fig. 1 is a block diagram of the telephone 
communication system of the present invention; 

Fig. 2 is a block diagram illustrating the system 
of Fig. 1 in different types of phone integration 
implementations ; 

Fig. 3 is a block diagram further illustrating the 
virtual phone application program interface of the 
systems of Figs. 1 and 2; 

Fig. 4 is a block diagram of an illustrative 
implementation of the abstraction layer in the systems 
of Figs. 1 and 2; and 

Fig. 5 is a block diagram illustrating a 
generalized form of the system of Fig. 1. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 



Telephone Communication System 
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A telephone communication system utilizing the 
virtual phone of the present invention is shown in Fig. 
1 wherein a PBX or similar digital switching device 12, 
a digital telephone 14 and an external device such as a 
personal computer (PC) or other processor 16 are 
interfaced by the arrangement 18 of the present 
invention. The virtual phone generic interface 18 of 
the present invention comprises a set 20 of virtual 
phone data structures, internal and external virtual 
phone application program interfaces 22 and 24, 
respectively, and a virtual phone host interface 26. 
Software designated hardware abstraction layer 28 
provides communication between the internal virtual 
phone application program interface 22, PBX 12 and the 
telephone set 14. 

Switch 12 can be a PBX, KSU, service provided by a 
central office (such as Centrex or ISDN) and does not 
even have to digital. Digital telephone 14 is 
representative of other 

communication devices like phones using emerging network 
interface technologies like internet protocol (IP), 
isoethernet, various forms of wireless, ATM, etc. 
Various types of additional telephones (ex. switch 
dependent phones, analog phones, cordless phones, 
conference phones), modems, fax machines or computers 
can be connected to the primary communications 
device 14. 

Virtual Phone Structure 

The actual virtual phone is represented by a set 20 
of data structures, for example *C" language data 
structures that maintain the current status of the 
theoretical, i.e. virtual, phone. The data in these 




structures may change when an event occurs on the switch 
12 or an adjunct digital phone 14, and the data gets 
passed up through the abstraction layer 28 and VPAPI 22. 
Also, the virtual phone structure information can change 
if an authorized external device 16 sends a VPAPI 
command 24. 

The virtual phone structure 18 requires several 
bytes of RAM within the address range of an embedded 
microcontroller. The current state of the structures 20 
matches what the switch 12 believes the digital phone 14 
to be. Since it is possible for applications in 
processor 16 to take control away from the digital set 
14, the virtual phone 20 and the digital phone 14 will 
not always have matching states. For example, if a 
digital phone and a cordless phone are connected to the 
same line, and voice is routed to the cordless, the 
switch thinks voice is active, and the digital phone 
does not. 

The messages sent form the telephone switch 12 
provide a representation of the state of the telephone 
14 as it resides internally in the switch. The virtual 
phone 18 translates this state into a form that is not 
switch or phone dependent, but one that can represent 
any desired telephone or communications device. The 
virtual phone 18 is protocol and transport dependent. 

The virtual phone system of the present invention 
is designed to fit the needs of different types of phone 
integration implementations. Of the three major 
components of the software system (Virtual Phone 
Structure 20, VPAPI 22, 24 and VPHI 26), not all need to 
be used in every system implementation. This is 
illustrated in the overview of Fig. 2. 
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In a first typical implementation, there is a case 
where the host interface is not needed. When an 
external communications device 34 is integrated into the 
system, the host protocol is unused. The external 
device 36 can be controlled directly from the system 
software within the micro-controller via the VPAPI 24 
via an integrated link 38. 

The auxiliary PC 16 from the arrangement of Fig. 1 
is shown connected to host interface 26' via an RS232 
link 40. 

In another example, all three major components are 
used. The external communications device is a computer 
44 with an ISA link 46 to the virtual phone system. 
This host computer 44 runs a TAPI application. As 
messages are received from the switch 12, the 
abstraction layer 28 calls VPAPI functions which update 
the virtual phone structures 2 0 and convert the commands 
into a generic protocol that can be easily understood by 
the host system 44. Optionally, the data does not even 
need to be maintained in the virtual phone structures. 
The system can act simply as a protocol converter. 

Also shown in the example of Fig. 2 is a network 
application 50 linked to the virtual phone system via a 
TCP/IP protocol link 52. 

The virtual phone data structures 20 of the virtual 
phone system 18 of Figs. 1 and 2 first will be described 
in detail, followed by description of the virtual phone 
application program interfaces 22, 24 and the 
abstraction layer 28. Accordingly, the following 
represents a description of all of the structures and 



defined variables that make up the structures 20 of the 
virtual phone system 18. 

Main Control Structure 

The following W C" language code illustrates the 
main virtual phone structure. One instance of this data 
structure is used to represent a single digital port. 



typedef struc 

VP_VOICE 
VP_RINGER 
VP_DI SPLAY 
BYTE 

VP BUTTON 



BYTE 
BYTE 



voice ; 
ringer; 
display; 
num_buttons ; 

button 

[VP_MAXBUTS] ; 
StandAlone; 

SwitchType; 

DigSetType 

Connections; 

ActivePhone ; 

TouchedPhone ; 



PassThroughFlags ; 
Voicemux; 



/* Main Virtual Phone 

Structure */ 

/* voice status */ 

/* ringer status */ 

/*LCD display status */ 

/* number of buttons 

actually in use */ 

/* button/lamp status */ 

/* operate without 

digital set */ 

/* type of switch 

connected */ 

/* Type of configured 

digital SET, if */ 

/* Which Phone Units are 

physically connected */ 

/* Which Physical Phone 

Unit is active */ 

/* Which Physical Phone 

Unit was last touched */ 

/* 0=switch l=digital 

set */ 

/* event block flags */ 
/* Bearer channel 
direction */ 



VIRTUAL_ 
PHONE; 



VP RINGER 



VP DISPLAY 



display 



num buttons; 



References the voice 
control element of the 
virtual phone. This 
is described in 
greater detail in the 
section titled "Voice 
control structure" . 
References the ringer 
control element of the 
virtual phone. This 
is described in 
greater detail in the 
section titled "Ringer 
control structure" . 
References the display 
control element of the 
virtual phone. This 
is described in 
greater detail in the 
section titled 
"Display control 
structure" . 
The number of the 
virtual buttons 
actually in use by the 
virtual phone. 
Although the virtual 
phone can support many 
buttons, some 
applications may limit 
the number of buttons 
in use. 



VP_BUTTON button [VP MAXBUTS] 



#define 
#def ine 



StandAlone; 



SwitchType; 



PBX_NONE 
PBX -ATT 



PBX NORSTAR 



References the button 
control element of the 
virtual phone. This 
is described in 
greater detail in the 
section titled 
* Button/Lamp control 
structure" . 
When TRUE, the system 
is operating without 
an adjunct digital 
phone. When FALSE, an 
adjunct digital phone 
is connected and 
operating. 

The brand of PBX (or 
KSU) connected to the 
system. The valid 
phone types are 
represented by the 
following defines: 

0 /* No PBX connected */ 

1 /* AT&T switch connected 
*/ 

2 /* Meridian switch 
connected */ 

3 /* Norstar switch 
connected */ 

4 /* Rolm switch connected 
*/ 

5 /*ISON switch connected 
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DigSetType; 



The type of digital 
phone connected to the 
system. The valid 
phone types are 
represented by the 
following defines: 



#def ine 
#def ine 

#define 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 
#def ine 



SET_NONE 
SET UNKNOWN 



SET_ 
SET_ 
SET_ 
SET_ 
SET_ 
SET_ 
SET_ 
SET_ 
SET_ 
SET_ 
SET_ 
SET_ 
SET_ 
SET_ 
SET_ 
SET 



ROLM_4 00 
ROLM_2 4 0 
ROLM_12 0 
ROLM_60 0 
ROLM_3 00 
Ml-2616 30 
NORJ7310 50 
NOR_72 08 51 
_NOR_7100 52 
NOR 7310LF 53 
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14 



_NOR_7 32 4 
ATTJ7 4 05 
_ATT_7 4 0 6 
ATTJ7 4 07 
ATT_7 434 
I SON 1 



/* Only when no PBX */ 
/* Connection, Unknown 
type */ 

/* Rolm Phone 400 */ 
/* Rolm Phone 240 */ 
/* Rolm Phone 120 */ 
/* Rolm Phone 600 */ 
/* Rolm Phone 300 */ 
/* Ml 2616 */ 
/* Norstar 7310 */ 
/* Norstar 7208 */ 
/* Norstar 7100 */ 
/* Norstar 7310 BLF */ 
/* Norstar 7324 */ 
/* AT&T 7405 */ 
/* AT&T 7406 */ 
/* AT&T 7407 */ 
/* AT&T 7434 */ 
/*ISON 1 */ 



Connections ; 



PHONE NONE 



PHONE ADJUNCT 0x01 



PHONE AUX 



PHONE CONF 



ActivePhone ; 



A mask of all of the 
physical phone 
connections made to 
the system. Multiple 
phones may be 
connected at any time. 
If the bit represented 
by the following 
defines is set in this 
field, the associated 
unit considered 
connected. 

/* No phones connected 
*/ 

/* the Standard digital 
set */ 

/* phone app via debug 
port V 

/* conference speaker 
phone */ 

Identifies which 
physical phone unit is 
currently active. A 
phone is defined to be 
active if it has 
control of the voice 
channel. The valid 
values for this field 
are the same as those 
defined for the 
* Connections" field 
above . 
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Touched Phone; 



Carrier [2] 



CARRIER_DEVICE_ 
SWITCH 

CARRIER_DEVICE_ 
ADJUNCT 

CARRIE R_LEVEL_ 
LOSS 

CARRIER_LEVEL_ 
GAIN 

CARRIE R_LEVEL_ 
UNKNOWN 



Identifies which 
physical phone unit 
was last used by the 
operator. This is 
used to determine the 
unit to receive 
'"active'' status. The 
valid values for this 
field are the same as 
those defined for the 
'Connections" field 
above . 

Identifies the carrier 
status of the switch 
and the phone . The 
first set of defines 
indexes the unit, the 
second set represents 
the status. 
0/* switch device */ 

1/* phone carrier device 
*/ 

0/* No carrier */ 

1/* Carrier */ 

2/* Unknown carrier 
state */ 
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BYTE PassThroughFlags A bit mask used to 

inform the abstraction 
layer which types of 
events should be 
passed between the 
switch and the phone, 
and which should be 
blocked. 

#define PASS_HOOK 0x01 /* hook switch from 

set */ 

#define PASS_BUTTON 0x02 /*buttons from set 

*/ 

#define PASS_LAMP 0x04 /*lamp updates from 

switch */ 

ttdefine PASSJDISPLAY 0x08 /* display update 

switch */ 

#define PASS_RINGER 0x10 /* ring updates 

switch */ 

BYTE VoiceMux; Identifies the 

direction of each of 
the available bearer 
channels. This is a 
bit mask with each bit 
representing each of 
the channels. 
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There is typically one 
bit for the voice 
channel, and at least 
one bit for available 
data channels. When 
the bit is low, the 
channel is directed to 
the adjunct digital 
telephone. When the 
bit is high, the 
channel is directed to 
the alternate device. 

#define VMUX_ADJUNCT 0 /* channel to 

digital set */ 

#define VMUX_AUX 1 /* channel to 

alternate */ 

#define VMUX_VOICE 0x01 /* bit 0 : voice 

channel */ 

#define VMUX_DATA 0x02 /* bit 1 : 1st 

data channel */ 

#define VMUX_DATA1 0x02 /* bit 1: 1st data 

channel */ 

#define VMUX_DATA2 0x04 /* bit 2 : 2nd 

data channel */ 

Voice control structure 

The following "C" language code defines the 
structure used to represent the state of the voice 
channel. A single instance of this structure is built 
into the main virtual phone structure. 



typedef struct 



/* Virtual Phone Voice 
Structure */ 
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BYTE active; 

BYTE unit; 

BYTE volume; 
VP_VOICE 

BYTE active; 

BYTE unit; 




/* l=active O=not active 
*/ 

/* mask active unit 
VOICE_???? */ 

/* voice mute, low, high, 
etc. */ 

When TRUE, the voice 
path is currently 
active. When FALSE, the 
voice path is not 
active . 

Which unit (within the 
confines of the digital 
set) is currently used 
as the communications 
source . 



#define VOICE_HANDSET 

#define VOICE_SPEAKER 

#define VOICE_HEADSET 

BYTE volume; 

#define VOICE_MUTE 

#define VOICE_NORMAL 

#define VOICE_LOW 

#define VOICE LOW 



0x10 /* Phone Handset 

Unit */ 
0x20 /* Phone Speaker 

Unit */ 
0x30 /* Phone Headset 

Unit */ 

The current sound level at 
which the system is 
operating . 

0x01 /* Volume is muted 

*/ 

0x02 /* Volume is normal 

*/ 

0x03 /* Volume is low */ 

0.04 /* Volume is high 



Ringer control structure 

The following W C" language code defines the 
structure used to represent the ring state of the 
virtual phone. A single instance of this structure is 
built into the main virtual phone structure. 



typedef struct 



VP RINGER; 



/* Virtual Phone 
Ringer Structure 
*/ 

/* 1: active 0=not 
active */ 
/* list of 
current cadence 
type */ 
/* list of 
current tone type 
*/ 



active; When TRUE, the ring state 

of the virtual phone is on. 
Typically, an audible ring 
indication can be heard. 
When FALSE, the ring state 
is off. 

cadence; One of the many difference 

types of ring cadence 
patterns a phone may 
select. This is valid when 
the ring state is active. 



#define RINGER_CAD_OFF 1 
#define RINGER CAD ON 2 



/* ring off */ 

/* ringer on steady */ 
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#define R I NGE R_C AD_2 3 /* ringer some on/off 

comb . * / 



BYTE tone; Once of the many different ring tones 
a phone may select. This is valid 
when the ring is active. 



#def ine 


RINGER_ 


_TONE_ 


_OFF 


1 


/* 


tone 


off */ 


#def ine 


RINGER_ 


_TONE_ 


_A 


2 


/* 


tone 


A 


*/ 


#def ine 


RINGER_ 


_TONE_ 


_B 


3 


/* 


tone 


B 


*/ 


#def ine 


RINGER_ 


_TONE_ 


_C 


4 


/* 


tone 


C 


*/ 


#def ine 


RINGER_ 


_TONE_ 


_D 


5 


/* 


tone 


D 


*/ 


#def ine 


RINGER_ 


_TONE_ 


_E 


6 


/* 


tone 


E 


V 


#def ine 


RINGER_ 


_TONE_ 


_F 


7 


/* 


tone 


F 


*/ 


#def ine 


RINGER 


_TONE_ 


_G 


8 


/* 


tone 


G 


*/ 


#def ine 


RINGER_ 


_TONE_ 


_H 


9 


/* 


tone 


H 


*/ 



Display control structure 

The following *C" language code defines the 
structure used to represent the LDC display of the 
virtual phone. A single instance of this structure is 
built into the main virtual phone structure. 



typedefstruct /* Virtual Phone 

Display Structure */ 
BYTE grid [VP_MAXROWS] /* The display text 

[VPD_MAXCOLS] ; */ 
VP_CURSOR cursor /* current cursors*/ 

[ VP D_MAX CURSORS] ; 
BYTE NumRows; /* Number of Rows on 

this page */ 
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NumColumns ; 

NumCursors ; 



BYTE IsClear; 
VP_DISPLAY; 



/* Number of Columns 
on this page */ 
/* Number of 
available cursors */ 
/* True if the 
display has 
stabilized */ 
/* True if the 
display is clear */ 



grid [VPD_MAXROWS] 
[VPD_MAXCOLS] ; 



The 2 dimensional 
array containing the 
characters on the 
display of the 
virtual phone. Each 
cell of the grid 
contains the 
character value in 
ASCII format. 
VPD_MAXROWS and 
VPD_MAXCOLS can be 
defined to support 
virtual displays of 
various sizes. 
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VP_CURSOR cursor [VPD_MAXCURSORS ] ; A 

list of cursors that 
are used by the 
display. Some 
displays have a 
single cursor, some 
have multiple 
cursors. This 
structure gives the 
abstraction layer 
control of all used 
cursor positions. 

BYTE NumColumns; Number of columns on 

the display for the 
current virtual phone 
implementation. 

BYTE IsStable; This is true if the 

display has been 
stable for a period 
of time determined by 
the abstraction 
layer. Only when the 
display goes stable 
does the information 
get transferred to 
the host. 

BYTE IsClear; True if the display 

is clear. 

The following "C" language code defines the structure 
used to represent a cursor device of the virtual phone. 
The display functions may use several cursors which must 
be maintained in order to generate the correct display. 
This structure is part of the main display structure. 



typedef struct 



}VP_BUTTON; 
BYTE row; 



/* Virtual Phone 
Cursor Structure */ 
row; /* Current row for 

this cursor */ 
col; /* Current column for 
this cursor */ 

Current row for this 
cursor within the 
current display. 
BYTE col; Current column for 

this cursor within 
the current display. 

Button/Lamp control structure 

The following *C" language code defines the structure 
used to represent a button/lamp device of the virtual 
phone. The main virtual phone structure uses a list of 
these items to represent all of the possible 
buttons/lamps on the phone. 

typedefstruct /* Virtual Phone 

Button/Lamp Structure 



deviceMask; 



press ID; 



release ID; 



lamplID; 



lamp2ID; 



/* mask showing which 
of next 4 are valid 
*/ 

/* ID of button press 
info */ 

/* ID of button 
release info */ 
/* ID of first lamp 
*/ 

/* ID of second lamp 
*/ 



BYTE 

VP_BUTTON; 
BYTE 
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buttonState; 

lampl State; 

lamp2State; 

deviceMask; 



#define VDP_MASKPRESS 
#define VDP_MASKRELEASE 
ttdefine VDP_MASKLAMP1 




/* state of button: 
l=down 0=up */ 
/* state of first 
lamp */ 

/* state of second 
lamp */ 
A mask which 
identifies the 
available components 
of the button/lamp. 
In some cases, button 
may exist without a 
lamp, in others, 2 
lamps may relate to a 
single button. Also, 
some buttons have 
press and release 

codes, while others 

only have a press 

code. This mask 

validates the fields 

xv press ID" , 

* releaselD" , 

* lampl ID", and 

* lamp 2 ID" by setting 

the associated 

defined bit. 

0x01 /* "pressID" is 

valid */ 

0x02 /* "releaselD" 
is valid */ 
0x04 /* "lamplID" is 
valid */ 
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VDP_MASKLAMP2 

pressID; 



0x0 8 /* "lamp2ID" is 
valid */ 

The raw integration 
dependent ID sent to 
the switch when the 
button is pressed. 
This field is only 
valid when the 
VDB_MASKPRESS bit is 

set in the 

* deviceMask" field. 

Typically, all keys 

have this field 

active . 

The raw integration 
dependent ID sent to 
the switch when the 
button is released. 
This field is only 
valid when the 
VDB_MAS KRE LEAS E bit 
is set in the 
* deviceMask" field. 
Typically, keypad 
buttons do not use a 
release ID. 
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BYTE 



lamp 1 ID; 



The raw integration 



dependent ID sent by 
the switch during a 
lamp update. This 
field is only valid 
when the 

VDB_MASKL.AMP1 bit is 
set in the 
"deviceMask" field. 
Buttons that do not 
have associated 
lights (such as 
keypad buttons) will 
not use this field. 



dependent ID sent by 
the switch during a 
lamp update. This 
field is only valid 
when the 

VDB_MASKLAMP2 bit is 
set in the 
w deviceMask" field. 
AT&T is the only 
integration known to 
use a second lamp for 
a button/lamp device. 



BYTE 



lamp2ID; 



The raw integration 



buttonState; 



#def ine 
#def ine 



#def ine 
#def ine 
#def ine 



BUTTON_PRESS 
BUTTON RELEASE 



lamplState; 



LAMP_STATE_OFF 
LAMP_S TATE_ON 
LAMP_S T ATE_FLAS H 

LAMP STATE FLUTTER 



Current state of the 
button. All buttons 
can be pressed or 
released. The hook 
switch is considered 
pressed when off 
hook, and released 
when on hook. 

1 /* button press */ 

2 /* button release 
*/ 

Current state of the 
first (primary) lamp. 
The lamp can be in 
any of the following 
states . 

1 /* lamp off */ 

2 /* lamp on V 

3 /* lamp flashing 



/* lamp fluttering 



#def ine 
#def ine 



#def ine 
BYTE 



LAMP_STATE_WINK 
LAMP STATE FLICKER 



LAMP_S T ATE_MI S C 1 
lamp2State; 



5 /* lamp winking */ 

6 /* lamp flickering 
*/ 

7 /* lamp misc */ 
Current state of the 
second lamp (AT&T is 
the only switch that 
uses this) . The lamp 
can be in any of the 
states as in the 

* lamplState" field. 



Button/Lamp index descriptions 

In the main virtual phone structure, the field 
w VP_BUTTON button [VP-MAXBUTS ] " is used to store the 
button/ lamp information for the virtual phone. The 
define VP_MAXBUTS determines the maximum number of 
buttons/lamps the virtual phone can contain. There 
are standard buttons in all configurations of the 
virtual phone. There are also additional buttons 
that may vary from phone to phone. The values shown 
below define the indices into the array of 
button/lamp control structures within the main 
virtual phone. 



#def ine 

#def ine 
#def ine 
#def ine 
#def ine 



#def ine 
#def ine 
KEY HOOK 



0 /* Hook switch key 
*/ 

1 /* Hold key */ 

2 /* Transfer key */ 

3 /* Release key */ 

4 /* Key Pad 0-9, *, 
# */ 

16 /* -start of non- 
fixed buttons - */ 

16 /* Prime Line */ 

17 /* */ 

When pressed, it is 



KEY RELEASE 



KEY_HOOK 

KEY_HOLD 
KEY_XFER 
KEY_RE LEASE 
KEY_PAD 

KEY_NONFIXED 

KEY_PRIME 
KEY_OTHER 
The hook switch, 
considered off hook. When released, on 
hook. All integrations have this key. 
The standard hold key. All integrations 
have this key. 

The transfer key. All integrations have 
this key. 

The release key. All integrations have 
this key. 
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The start of the key pad keys. The 
sequence of keys are in the following 
order. 0 through 9, *, and #. All 
integrations have these keys. 
The starting ID of the non-fixed keys. 
Keys at this index for higher can be 
custom configured. 

The key associated with a prime line. 
When the switch has a prime line 
configured for a phone, this index should 
reference that key. 

Additional keys. Configuration is 
flexible . 

(Virtual Phone Application Program 
Interface) 

Access to the virtual phone structures is available 
through a set of symmetric functions known as the VPAPI 22 
and 24. The VPAPI 22, 24 provides a mechanism to transfer 
data between the virtual phone data structures 20, and all 
devices (such as the switch 12, phones 14, and the external 
device 16) . The data structures 20 are changed only via 
this interface, never directly by an external function 16. 
All elements of the data structures 2 0 can be modified, and 
read through the VPAPI 22, 24. Whenever the abstraction 
layer software 28 receives a change from the switch 12, 
digital phone 14, or external device 16, a call is made to 
a VPAPI function with parameters specifying the update 
request. The VPAPI function first validates the command 
request, and then makes the appropriate modification to the 
virtual phone structure. 

As shown in Fig. 3, for different switches 12a, 12b, 
12c and 12d and phones 14a, 14b, 14c, 14d from various 



KEY NONFIXED 



KEY PRIME 



KEY OTHER 
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vendors different abstraction layers 28a, 28b, 28c and 28d 
are provided. The VAPI 22, 24 also provide data transfer 
between the virtual phone data structures 20 and various 
devices such as serial devices 60, DSP 62, conference 
phones 64 and other devices 66. 

Whenever a valid state change is made to the virtual 
phone structure 20, the VPAPI 24 calls a second function 
which is responsible for converting the information into a 
generic protocol (Host Interface 26), and transmitting it 
via the host interface 16 to the host system. 

The abstraction layer 2 8 (and external device queries) 
often need information on the current state of the virtual 
phone. Symmetric VPAPI 22, 24 functions are used for this 
purpose and for all aspects of data access. In order to 
retrieve current status information and pass that 
information to the abstraction layer 2 8 and an external 
device 16, a function beginning with '*vp_Get // is used. To 
modify data, v vp_Set" is used, which in turn automatically 
calls a function beginning with *vp_Send" for external 
transfer. Or, for example, to set a light state in the 
virtual phone structure, a call is made to 

w vp_SetLampState" with the lamp ID and state as parameters. 
For the abstraction layer 28 or external device 16 to get 
the light state, a call to the symmetric function 
w vp_GetLampState" is made. 

The abstraction layer 2 8 (and external device queries) 
often need information regarding the current state of the 
virtual phone. Symmetric VPAPI functions are available for 
this purpose. Thus, during the processing of switch and 
phone packets, the abstraction layer 28 often calls the 
VPAPI functions 22, 2 4 to maintain current status of the 
digital phone 14 in the virtual phone data structures 20. 
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Primarily, the w vp_Set" type functions are used. When a 
simulated event occurs, such as a generic cordless unit 
going off hook, the application code may also make a call 
to the *vp_Set" function, causing the system to be in the 
off hook state. Also note that in order for the simulated 
event to affect the switch, it must pass through the 
abstraction layer through an API function of the form 
* vprolm_DoButton" for example. 



The hardware abstraction layer 2 8 is not part of the 
virtual phone, but is a system component used to interface 
between the switch 12 (and phone 14) and the virtual phone 
18. The specifications for building this block vary for 
each switch type. In the example of Fig. 4, building of an 
ISDN integration is shown for use with an ISDN switch 72 
and ISDN phone 74. 



The first layer 80 (Physical layer) of the hardware 
abstraction can be built based on the international 
standards ITU I-series and ITU G-series documents. The 
second layer 82 (Data Link layer) is defined in the ITU 
Q.920 through Q.923 documents. The third layer 84 (Network 
layer) is defined in the ITU Q.930 through Q.939 documents. 
These specifications taken together define how to build the 
hardward abstraction block 28 for virtual phone support 
built on top of an ISDN switch. 



Initialization Functions 



The following functions are used for initialization 
and are typically only called system on startup. 



32 



vp_init () 



vp_init_pbx_ 
type ( ) 



vp_init_set_ 
type ( ) 



Performs general virtual phone 
initialization such as allocating data 
and variable initialization. This 
function is called by the main 
application once during startup. 
Performs initialization specific to a 
particular switch. This function is 
called automatically by the virtual phone 
system when the VPAPI function 
* vp_SetPbxType" is called. Normally, 
this happens only once at startup. 
Performs initialization specific to a 
specific digital telephone. This 
function is called automatically by the 
virtual phone system when the VPAPI 
function * vp_SetSetType //r is called. 
Normally, this happens only once at 
startup . 



Configuration Control Functions 

These functions are used to manage system 
configuration information between the main application and 
the virtual phone. 

vp_SendPbxType (BYTE resp) 
vp_GetPbxType (BYTE *type) 
vp_SetPBXType (BYTE type) 



The foregoing three functions configure the 
virtual phone 2 0 with the current physically 
connected type of switch 12. After the main 
application determines which switch is connected, 
it calls the Set function. The Set function 
automatically call vp_ini t_pbx_type () . 




- 33 - 

type One of the following defined variables 
representing the switch type. 



PBX_NONE No switch connected (default) 

PBX_ATT AT&T switch connected 

PBX_M1 Meridian switch connected 

PBX_NORS TAR Norstar switch connected 

PBX ROLM Rolm switch connected 



resp The type of data to be transmitted to the serial 
port . 



QUERY_RE S P ONS E No change, serial packet is 

due to a query 
DELTA_RESPONSE The state of the virtual 

phone has changed 



vp_S ends et Type (BYTE resp) 
vp_GetSetType (BYTE *type) 
vp-SetSetType (BYTE type) 



The foregoing three functions configure the 
virtual phone 20 with the current physically 
connected type of digital telephone. After the 
main application 16 determines which digital 
phone is connected, it calls the set function. 
The Set function automatically calls 
vp_init_set_type (). 

type One of the following defined variables 

representing the switch type. 



SET NONE 



No digital phone connected 
(default) 



SET_UNKNOWN 

SET_ROLM_4 00 
SET_ROLM_240 
SET_ROLM_12 0 
SET_ROLM_60 0 
SET_ROLM_300 
SET_M1_2 616 
SET_NOR_7310 
SET_NOR_72 0 8 
SET_NOR_7100 
SET_NOR_7310BLF 

SET NOR 7324 



Digital set of unknown type 
connected 

Rolm RP400 set connected 
Rolm RP240 set connected 
Rolm RP120 set connected 
Rolm 600 series set connected 
Rolm 300 series set connected 
Meridian 2616 set connected 
Norstar 7310 set connected 
Norstar 7208 set connected 
Norstar 7100 set connected 
Norstar 7310 BLF set 
connected 

Norstar 7324 set connected 



resp The type of data to be transmitted to the serial 
port 26. 



QUE RY_RE S P ON S E 
DELTA RESPONSE 



No change, serial packet is 
due to a query 
The state of the virtual 
phone has changed 



vp_SendConnections (BYTE resp) 
vp_GetConnections (BYTE *mask) 
vp_SetConnections (BYTE mask) 



The foregoing three functions configure the 
virtual phone 20 with a list of physically 
connected phones. The main application 16 will 
determine the types of phone units that will have 
access to the system. Once determined, it calls 
this functions with a mask representing current 
connections . 



mask A bit mask used to correspond to up to 8 phone 

units. If the bit for given phone type is on in 
the mask, that phone is connected in the system. 



PHONE_NONE No phones connected (default) 

PHONE_ADJUNCT The compatible digital phone 

is connected 
PHONE_AUX The serial link based phone 

is connected 
PHONE_CS1000 The analog conference phone 

is connected 



resp The type of data to be transmitted to the serial 
port 26. 



QUERY_RES PONSE No change, serial packet is 

due to a query 
DELTA_RES PONSE The state of the virtual 

phone has changed 



Voice MUX Control Functions 



When multiple phones are connected to the system at 
one time, it is necessary to maintain which of the phones 
is physically in use. The virtual phone 20 needs this 
information so that it can direct voice data to the proper 
phone. Once a phone has * control" of the voice, the 
virtual phone 20 is responsible for blocking other units 
from taking dangerous actions (such as terminating the 
call) . 



The key elements the virtual phone 2 0 is concerned 
with are the current control, and the last touched unit. 
These values enable the virtual phone to manage call 
control seamlessly between connected phone units. 



- 36 - 

vp_SendActivePhone (BYTE) resp) 
vp_GetActivePhone (BYTE *type) 
vp_SetActivePhone (BYTE type) 



The foregoing three functions configure the 
virtual phone 20 with the current active phone 
14. A phone is considered active if the voice 
path is active, and is directed toward that 
phone. The active phone is also known to be the 
phone with * control" . 



type The phone type ID of the connected phones that 

currently has control. The phone type must be in 
the connections mask list. 



PHONE_NONE Idle, no phones have control 

(default) 

PH0NE_AD JUNCT The compatible digital phone 

has control 

PHONE_AUX The serial link based phone 

has control 

PHONE_CS1000 The analog conference phone 

has control 



resp The type of data to be transmitted to the serial 
port. 



QUERY_RESPONSE No change, serial packet is 

due to a query 
DELTA_RESPONSE The state of the virtual 

phone has changed 



vp_SendTouchedPhone (BYTE resp) 
vp_GetTouchedPhone (BYTE *type) 
vp_SetTouchedPhone (BYTE type) 



The foregoing three functions configure the 
virtual phone 20 with the last touched phone. 
When the user presses a button, or goes off hook 
on a particular phone, it is considered touched. 
When a call is terminated, no phones are 
considered touched. The phone to go active will 
always be the phone with the current touched 
status . 

type The phone type ID if the connected phones that 
was last used by the operator. The phone type 
must be in the connections mask list. 



PHONE NONE 



PHONE ADJUNCT 



PHONE AUX 



PHONE CS1000 



Idle, no phones have control 
(default) 

The compatible digital phone 
has control 

The serial link based phone 
has control 

The analog conference phone 
has control 



resp The type of data to be transmitted to the serial 
port . 



QUERY_RE S P ONS E 



No change, serial packet is 
due to a query 



DELTA RESPONSE 



The state of the virtual 
phone has changed. 



Voice Control Functions 



The functions are used to manage all voice related 
information within the virtual phone 20. Voice active 





- 38 - 

status, volume, and physical unit on a phone are all 
maintained . 

vp_SendVoiceState (BYTE resp) 
vp_GetVoiceLevel (BYTE * level) 
vp_GetVoiceUnit (BYTE *unit) 
vp_GetVoiceVolume (BYTE * volume) 
vp_SetVoiceLevel (BYTE level) 
vp_SetVoiceUnit (BYTE unit) 
vp_SetVoiceVolume (BYTE volume) 

The foregoing seven functions configure the 
virtual phone 20 with the current voice status. 
Whenever the switch 12 activates or deactivates 
the voice path, these functions are called. Some 
switches and phones have the ability to activate 
the voice path at different volumes, and on 
different units (such as headset or 
speakerphone) . 

level When TRUE, the system voce path is active. When 

FALSE, it's inactive. See vp_GetActivePhone to 

determine which phone has control of the voice 
path. 

unit The unit on the phone which is in use by the 
operator . 

VOICE__HANDSET The standard handset found on 



VOICE HEADSET 



VOICE_SPEAKER 



most phones 

The speaker/microphone (found 
on some phones) 
An auxiliary headset unit 
(usually a separate plug in 
device) 
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volume The volume at which voice can be heard through 
the phone . 



VOICE_MUTE Voice active, but volume 

muted 

VOICE_NORMAL Normal voice volume 

VOICE_LOW Volume audible, but lower 

than normal 

VOICE_HIGH Volume higher than normal 



resp The type of data to be transmitted to the serial 
port . 



QUE R Y_RE S P ON S E No change, serial packet is 

due to a query 
DELTA_RESPONSE The state of the virtual 

phone has changed 



Ringer Control Functions 



These functions are used to manage all ringer related 
information within the virtual phone 20. Ringer active 
status, cadence, and tone during ring are all maintained. 



vp_SendRingerState (BYTE resp) 
vp_GetRingerLevel (BYTE * level) 
vp_SetRingerCadence (BYTE *cadence) 
vp_GetRingerTone (BYTE *tone) 
vp_SetRingerLevel (BYTE level) 
vp_SetRingerCadence (BYTE cadence) 
vp_SetRingerTone (BYTE tone) 



The foregoing seven functions configure the 
virtual phone 2 0 with the current ringer status. 
Whenever the switch 12 turns the audible ringer 
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on or off, these functions are called. Different 
switches use different ring cadences and ring 
tones. The virtual phone 20 maintains this 
information . 

level When TRUE, the ringer is considered active. 

On some switches, the ringer may be active 
for the full duration of a ring cycle. In 
others, it may be active only when the 
audible ringing sound is heard. When FALSE, 
the ringer is not active. 

cadence The cadence at which the switch is sending 
the ring signal. 

RINGER_CAD_OFF No ring cadence 

RINGER_CAD_ON Standard ring cadence active 

RINGER_CAD_2 Alternate ring cadence active 

Tone The tone at which the ring is heard. 



RINGER TONE OFF 


No audible tone 


RINGER_TONE_A 


Tone 


A 


RINGER_TONE B 


Tone 


B 


RINGER_TONE_C 


Tone 


C 


RINGER_TONE D 


Tone 


D 


RINGER_TONE E 


Tone 


E 


RINGER_TONE_F 


Tone 


F 


RINGER_TONE G 


Tone 


G 


RINGER TONE H 


Tone 


H 



resp The type of data to be transmitted to the serial 
port . 
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QUE R Y_RE S P ON S E 



No charge, serial packet is 
due to query 



DE L AT_RE S P ON S E 



The state of the virtual 



phone has changed 



Lamp Control Functions 

These functions are used to manage all lamp (LED or 
light) related information within the virtual phone 20. 
Many lamps typically exist on a given system. The virtual 
phone has the facility to store the state of any of these 
lamps. It is also possible to pass the lamp update 
information directly to the host system. In this case, the 
virtual phone just passes the information through without 
maintaining it. 

In the case where the lamp is stored in the virtual 
phone, any of the functions can be used to read or write 
data. The functions with the W V" in the name require the 
virtual phone index of the lamp. The remaining functions 
work directly with the raw ID. The *Ex" of extended 
functions allow for multiple bytes of raw ID information. 

When the lamp status is not maintained within the 
virtual phone structures, only the functions working with 
the raw IDs can be used. These functions will simply pass 
the update information directly to the host without storing 
any information within the virtual phone structures. 

vp_SendVLampState (BYTE resp, BYTE vid) 

vp_SendLampState (BYTE resp, BYTE len, BYTE*rawidlist, BYTE 
state) 

vp_GetVLampState (BYTE vid, BYTE * state) 
vp__SetVLampState (BYTE vid, BYTE state) 
vp_SetLampState (BYTE rawid, BYTE state) 



vp_SetLampState (BYTE len, BYTE *rawidlist, BYTE state) 

rawid The raw ID sent from the switch. The 

virtual phone checks to see if this lamp is 
configured as part of the defined phone. If 
so, a look up is done to get the virtual 
index (vid) of the correct button/lamp 
index . 

rawidlist A list of raw IDs sent from the switch. 

This is used when more than one byte of 
information is needed to reference the lamp. 
The w len" parameter is used to define the 
number of bytes in this list. 

len The number of bytes in the * rawidlist" . 

state The state of the lamp. 



L AMP_S TAT E_0 F F Lamp is dark 

LAMP_STATE_ON Lamp light is on steady 

LAMP_S TATE_FLAS H Lap is on in a flashing 
pattern 

LAMP_STATE_FLUTTER Lamp is on in a fluttering 
pattern 

LAMP_STATE_WINK Lamp is on in a winking 

pattern 

LAMP_S TATE - FL I CKER Lamp is on in a flickering 
pattern 

LAMP_STATE_MISC1 Lamp is on in an unknown 
pattern 



vid The ID within the virtual phone 2 0 for the lamp. 

Each Button/Lamp control structure has fields for 
lamp information. Only certain buttons/ lamps are 
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defined to be as part of the virtual phone 20. 
This field is an index into the virtual phone's 
button/lamp structure. (See section Button/Lamp 
index descriptions) 

resp The type of data to be transmitted to the serial 
port 26. 

QUE R Y_RE S P ON S E No change, serial packet is 

due to a query 

DELTA_RESPONSE The state of the virtual 

phone has changed 

Button Control Function 

These functions are used to manage all button and hook 
switch related information within the virtual phone. A 
hook switch and many buttons typically exist on a given 
system. The virtual phone has the facility to store the 
state of any of these buttons. It is also possible to pass 
the button press/release information directly to the host 
system. In this case, the virtual phone just passes the 
information through without maintaining it. 

The hook switch is considered a button and is always 
defined as button number zero in the virtual phone. 

In the case where the button is stored in the virtual 
phone, any of the functions can be used to read or write 
data. The functions with the "V" in the name require the 
virtual phone index of the button. The remaining functions 
work directly with the raw ID. The *Ex" of extended 
functions allow for multiple bytes of raw ID information. 
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When the button status is not maintained within the 
virtual phone structures, only the functions working with 
the raw IDs can be used. These functions will simply pass 
the update information directly to the host without storing 
any information within the virtual phone structures. 

vp_SendVButtonState (BYTE resp, BYTE vid) 
vp_SendButtonState (BYTE resp, BYTE len, BYTE* rawidlis t , 
BYTE state) 

vp_GetVButtonState (BYTE vid, BYTE *state) 
vp_SetVButtonState (BYTE vid, BYTE state) 
vp_SetButtonState (BYTE rawid, BYTE state) 

vp_SetButtonState (BYTE len, BYTE *rawidlist, BYTE state) 

rawid The raw ID sent from the switch. The virtual 
phone 20 checks to see of this button is 
configured as part of the defined phone. If so, 
it is used to reference the correct button/lamp 
index . 

rawidlist A list of raw IDs sent from the switch. 

This is used when more than one byte of 
information is needed to reference the 
button. The *len" parameter is used to 
define the number of bytes in this list. 

len The number of bytes in the * rawidlis t" . 

state The State of the button or hook switch. Buttons 
can be either pressed or released. The hook 
switch is considered pressed when off hook, and 
released when on hook. 



BUTTON_PRESS Button has been pressed 
BUT T ON_RE LE AS E Button has been released 
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vid The ID within the virtual phone 20 for the button 
or hook switch. Each Button/Lamp control 
structure has fields for button information. 
Only certain buttons/lamps are defined to be as 
part of the virtual phone. This field is an 
index into the virtual phone' s button/lamp 
structure. (See section Button/Lamp index 
descriptions) . 

resp The type of data to be transmitted to the serial 
port . 

QUE R Y_RE S P ON S E No change, serial packet is due to 
a query 

DELTA_RESPONSE The state of the virtual phone has 
changed 

Hook Switch Control Functions 

The hook switch is just a button. Button index zero is 
always fixed to the hook switch. Because of this, the 
button API calls can be used for hook switch control. 
However, for simplication sake, a set of API function are 
provided for direct hook switch control. 

vp_SendHookState (Byte resp) 
vp_SetHook_State (BYTE state) 
vp_GetHookState (BYTE * state) 

state The state of the book switch. 

HOOK_OFF Off hook (Same as button press) 
Hook_ON On hook (Same as button release) 
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resp The type of data to be transmitted to the serial 
port . 

QUE R Y_RE S P ON S E No change, serial packet is due to 
a query 

DELTA_RESPONSE The state of the virtual phone has 
changed 

Display Control Functions 

The virtual phone supports the ability to maintain a 
flexible display. These functions provide the abstraction 
layer the ability to build the display in a way similar to 
how the switch puts information on the display. 

The abstraction layer calls the "update" functions to 
send text changes to the display as they are received from 
the switch. Addressing is either direct (by row and column 
number), or based on a cursor position. The switch often 
clears single rows or even the entire display with one 
command. An API function exists for each of these tasks. 

Often, more than one cursor exists for a given display. 
The abstraction layer passes the cursor index whenever a 
display update at cursor type command is given. An API 
command exists to maintain each current cursor position. 

When the display has been stable (has not changed) for 
a given period of time, or the switch sends a * display 
stable" command, the abstraction layer calls the 
*vp_dDisplayIsStable" function. This triggers the virtual 
phone to send the display contents to the host. 

vp_SendDi splay (BYTE resp) 
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vp_dDisplayIsStable ( ) 
vp_dClearDisplay ( ) 
vp_dClearRow (BYTE row) 

vp_dSetCursor Position (BYTE cindex, BYTE row, BYTE col) 
vp-dUpdateCharAtCursor (BYTE cindex, BYTE ch) 
vp_dUpdateCharAtCursor (BYTE cindex, BYTE *txt, BYTE len) 
vp_dUpdateCharAbsolute (BYTE row, BYTE col, BYTE ch) 
vp_dUpdateTextAbsolute (BYTE row, BYTE col, BYTE *txt, 
BYTE len) 

cindex The index of the cursor to be used to 

execute the function. This index is 
maintained separately and contains a row and 
column of where the text will be displayed. 

row The row number on which the text will be 

displayed . 

col The column number on which the text will be 

displayed. 

resp The type of data to be transmitted to the 

serial port. 

QUE R Y_RE S P ONS E No change, serial packet is 
due to a query 

DELTA_RESPONSE the state of the virtual 
phone has changed 



ch The ASCII character to be displayed. 

txt The ASCII text string to be displayed. 

len The number of characters in the ASCII text 

string to be displayed. 
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Carrier Control Functions 



The virtual phone maintains the carrier state of the 
switch, and the adjunct digital phone. This information is 
available via the following functions. 



vp_SendCarrier (BYTE resp, BYTE device) 
vp_SetCarrier (BYTE device, BYTE level) 
vp_GetCarrier (BYTE device, BYTE *level) 



device The physical device. 



CARRIER_DEVICE_SWITCH The switch 
CARRIER_DEVICE_AD JUNCT The adjunct digital 
phone 



level The carrier level 



CARRI ER_LEVEL_LOS S 
CARR I ER_LEVE L_GAI N 
CARRIER LEVEL UNKNOWN 



No carrier for the 
device 

The device has 
carrier 
Carrier state 
unknown 



resp The type of data to be transmitted to the serial 
port . 



QUERY_RESPONSE No change, serial packet is 

due to a query 
DELTA_RESPONSE The state of the virtual 

phone has changed 



Pass Through Control Functions 
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It is possible to block certain types of messages 
between the switch and the digital phone. The pass through 
flags set which messages are allowed to pass through, and 
which are blocked. The following APIs provide this 
functionality. 

vp_SendPAssThroughFlags (BYTE resp) 
vp_SetPassThroughFlags (BYTE flags) 
vp_GetPassThroughFlags (BYTE * flags) 

flags A bit mask with each bit representing a different 
pass through mode. If the bit is set, the 
message is allowed to pass. If cleared, the 
message is blocked. 

PASS_HOOK hook switch from digital set 

PASS_BUTTON button presses/releases from 

digital set 
PASS_LAMP lamp updates from switch 

PASS_DISPLAY display updates from switch 
PASS_RINGER ringer updates from switch 

resp The type of data to be transmitted to the serial 
port . 

QUE R Y_RE S P ON S E No change, serial packet is 
due to a query 

DELTA_RESPONSE The state of the virtual 
phone has changed 

Bearer Channel Control Functions 



The voice and data channels can be routed normally to 
the adjunct digital phone, or to another device. These 
functions control the routing of these bearer channels. 
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The system may want to instruct the virtual phone to send 
voice or data information to a unit other than the adjunct 
phone such as a conference phone or a DSP for processing. 

Since the digital data link between the switch and the 
phone typically provides a voice channel and at least one 
data channel, these functions use a bit mask to identify 
which of the channels to control. 

vp_SendVoiceMux (BYTE resp) 

vp_SetVoiceMux (BYTE devicemask, BYTE unit) 
vp_GetVoiceMux (BYTE devicemask, BYTE*unit) 

devicemask A bit mask with each bit representing one of 
the bearer channels to direct with the 
command 



VMUX VOICE 



voice channel 



VMUX DATA 



data channel 



VMUX_DATA1 



VMUX DATA2 



primary data channel 
secondary data channel 



unit 



The device where the channel is to be 



directed. 



VMUX_AUX 



VMUX ADJUNCT 



Adjust digital telephone 
The other connected unit 



(DSP, conference phone, etc.) 



resp 



The type of data to be transmitted to the 
serial port. 



QUERY_RE S P ONS E No change, serial packet is 
due to a query 



DELTA_RESPONSE The State of the virtual 
phone has changed. 

Virtual Phone Host Interface Protocol 

Communications between the virtual phone 2 0 and the 
external device, i.e. host system, is accomplished via an 
internally designed custom protocol called the Virtual 
Phone Host Interface Protocol (VPHIP) 26. Any time the 
virtual phone changes, a VPHIP packet is sent out to the 
host reflecting the update to the virtual phone structure. 
This keeps the auxiliary PC 16 up to date at all times with 
the current status of the virtual phone. 

The auxiliary PC 16 also has the ability to manipulate the 
virtual phone by sending VPHIP packets across the link. 
The virtual phone parses the VPHIP packet and calls the 
appropriate VPAPI function, which in turn may update the 
virtual phone structure. 

The functionality and structure of VPHIP is described 
as follows: 

Packet Format 

All packets adhere to the following format: 

Length Description Value 

1 Byte Header see note 

1 Byte Packet Length variable 

1 Byte Packet Description see below sections 

Variable Packet Data see below sections 
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The header byte follows specific rules. Any message 
originating from the switch 12 has a header of 0x01. 
Messages from the adjunct phone 14 have header 0x02. 
Messages from the auxiliary PC 1 6 have header 0x04. 
Informational messages (such as PBX type) have header 0x00. 
Queries, and responses to queries turn on the upper most 
bit of the header which result in header codes of 0x08, 
0x81 and 0x82. 

System Information messages 

System information packets are used to communicate phone 
status information between the internal virtual phone 2 0 
and the auxiliary PC 16. All system information packets 
have a header value of 0x00. 

Carrier State 

These packet types are used to identify the carrier 
condition of the switch or the digital telephone. 



Byte Description Value 

0 Header 0x00 

1 Packet Length 4 

2 Carrier (Switch) OxBO 

3 Carrier Level 

No Carrier 0 

Carrier 1 

Unknown 2 
Condition 

Byte Description Value 

0 Header 0x00 

1 Packet Length 4 



• 
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2 Carrier (Digital OxBl 
Set) 

3 Carrier Level 

No Carrier 0 
Carrier 1 
Unknown 2 
Condition 

Adjunct Phone Type 

The adjunct phone type packet is used to identify the 
type of digital phone (if any) that is physically connected 
to the interface board. 



Byte 


Description 




Value 


0 


Header 




0x00 


1 


Packet Length 




4 


2 


Adjunct Phone 


Type 


OxFl 


3 


Phone Index 








None 




0 




Unknown 




1 




Rolm RP4 00 




10 




Rolm RP24 0 




11 




Rolm RP120 




12 




Rolm RP600 




13 




Rolm RP300 




14 




Ml 2616 




30 




Norstar 7310 




50 




Norstar 7208 




51 




Norstar 7100 




52 




Norstar 7310 


BLF 


53 




Norstar 7324 




54 




AT&T 7405 




70 




AT&T 7406 




71 




AT&T 7407 




72 
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AT&T 7434 73 

Current Active Phone 

When more than one phone is connected to the interface 
board at the same time, it is often necessary to know which 
unit is actively communicating with the switch 12. This is 
necessary to establish such things as voice routing, and 
button filtering. This packet returns the physical phone 
description that is currently active. 



Byte Description Value 

0 Header 0x00 

1 Packet Length 4 

2 Active Phone Type 0xF2 

3 Unit Index 

None 0x00 

Adjunct Digital Set 0x01 

Auxiliary 0x02 

Conference Phone 0x04 

future use 0x08... 



Last Touched Phone 

When more than one phone is connected to the interface 
board at the same time, the user may operate either unit to 
make and receive calls. Knowing which physical unit was 
last touched enables the virtual phone 20 to route voice 
and control to the appropriate unit. 



Byte Description Value 

0 Header 0x00 

1 Packet Length 4 

2 Touched Phone Type 0xF3 



Physical Connections 



Unit Index 

None 0x00 

Adjunct Digital Set 0x01 

Auxiliary 0x02 

Conference Phone 0x04 

future use 0x08. 



The virtual phone 20 may support several controlling 
and/or monitoring devices simultaneously. This command is 
used to transfer the current configuration information. 
The connection information is stored as a bit mask 
providing space for up to 8 physical devices. 



Byte Description Value 

0 Header 0x00 

1 Packet Length 4 

2 Physical Cncts Type 0xF4 

3 Connection Mask 

None 0x00 

Adjunct Digital Set 0x01 

Auxiliary 0x02 

Conference Phone 0x04 

future use 0x08... 



Messages from the switch 



All messages originating from the switch 12 have a 
header value of 0x01. 



Voice Status 



The Voice Status packets are used to supply the current 
voice status to the auxiliary PC 16. The physical unit 
being used, and the volume are also supplied. 
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Byte Description Value 

0 Header 0x01 

1 Packet Length 5 

2 Voice Enable 0x10 

3 Unit 

Handset 0x01 

Speaker 0x02 

Headset 0x04 

4 Volume 

Mute 0 

Normal 1 

Low 2 

High 3 



Description Value 

Header 0x01 

Packet Length 3 

Voice Disable 0x11 

The Voice Enable command (0x10) explicitly activates 
the voice channel regardless of unit state. Voice Disable 
(0x11) explicitly de-activates voice. The Voice Status 
command (0x12) is a combination of the two where the 
presence of a bit in the unit mask is used to determine 
whether or not voice is active. 




Byte Description Value 

0 Header 0x01 

1 Packet Length 5 

2 Voice Status 0x12 

3 Unit 

Handset 0x01 

Speaker 0x02 

Headset 0x04 
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4 Volume 

Mute 0 

Normal 1 

Low 2 

High 3 

Ringer Status 

The ringer status packets are used to supply ringer 
status to the auxiliary PC 16. In addition to ringer 
status, the cadence and ring tone are also supplied. In 
some switches, the ringer turns on and off with the audible 
sound while the calling party is attempting to connect. It 
may be beneficial to leave the ringer in the "on" state and 
have the virtual phone use the * cadence off" condition 
between audible rings. This will give feedback similar to 
that of using the LED for incoming call status. 



Byte Description Value 

0 Header 0x01 

1 Packet Length 5 

2 Ringer Active 0x2 0 

3 Cadence 

Off 0 

On 1 

#2 2 

4 Tone 

Off 1 

A 2 

B 3 

C 4 

D 5 

E 6 

F 7 



Byte Description Value 

0 Header 0x01 



• 
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1 Packet Length 3 

2 Ringer Inactive 0x21 

Lamp Status (Generic) 

The Lamp status packet is used to supply lamp (LED) 
information to the Auxiliary PC 16. The internal virtual 
phone lamp ID (not the switch's raw ID), and the flash rate 
are passed in the packet. 

Byte Description Value 

0 Header 0x01 

1 Packet Length 5 

2 Lamp Update 0x30 

3 Flash Rate 

Off 1 

On 2 

Flash 3 

Flutter 4 

Wink 5 

Flicker 6 

Miscl 7 

4 Lamp ID 

Prime Line 16 

Others 17 

Lamp Status (Raw) 



The Raw lamp status packet is used to supply lamp (LED) 
information to the auxiliary PC. The raw ID received from 
the switch (not the internal virtual phone ID) , and the 
flash rate are passed in this packet. 



In the case where lamps have multiple bytes for the ID, 
the additional bytes are placed at the end of the packet 
and the length is changed accordingly. 



Byte 
0 



Description 
Header 



Value 
0x01 



• 
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1 Packet Length 

2 Lamp Update (Raw) 

3 Flash Rate 

Off 

On 
Flash 
Flutter 
Wink 
Flicker 
Miscl 

4 Lamp raw ID byte #1 

5 [Lamp raw ID byte 
#2] 

Display Status 

The Display status packets are used to supply display 
information to the auxiliary PC. These packets allow for 
portions of the display to be updated as they are received 
from the switch. The basis display packet supplies text 
and position information (the length can be extracted from 
the packet length byte) . There are other special packets 
that can be used for scrolling of flashing characters on 
the auxiliary PC. 



Byte Description Value 

0 Header 0x01 

1 Packet Length 5 + (length of 

text) 

2 Display Update 0x40 

3 Row variable 

4 Column variable 

5... Text * variable 

string" 



4 + number of 
raw ID bytes 

0x31 

1 
2 
3 
4 
5 
6 
7 
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The Clear Display packet can also be used to clear the 
entire display, or a single row of the display. 



Byte Description Value 

0 Header 0x01 

1 Packet Length 4 

2 Clear Display 0x41 

3 Row 

All rows 0 

Single row row number 



Messages from the Phone 

All messages originating from the PBX 12 have a header 
value of 0x02. 

Button Status (Generic) 

The virtual phone 20 is configured with a set of 
generic buttons used across all switches. These buttons 
(and associated lamps, if any), have fixed identifiers. 
Only the buttons with identifiers assigned to the virtual 
phone function with this command. 

The Button status packets are used to supply button 
press/release information originating from the adjunct 
phone to the auxiliary PC. 



Byte Description Value 

0 Header 0x02 

1 Packet Length 4 

2 Button Press 0x50 
(Generic) 



Hook Switch 0 (OFF hook) 

Hold 1 

Transfer 2 

Release 3 

Key Pad (0- 4-15 
9,*,#) 

Prime Line 16 

Others 17 



Byte Description Value 

0 Header 0x02 

1 Packet Length 4 

2 Button Press 0x51 
(Generic) 

3 ID 

Hook Switch 0 (ON hook) 

Hold 1 

Transfer 2 

Release 3 

Key Pad (0- 4-15 
9,*,#) 

Prime Line 16 

Others 17... 



Button Status (Raw) 



All buttons on all phones have a defined raw id. This 
command is used to transmit this raw id across the 
interface. Either this command, or the Generic button 
status command can be used to transmit button state 
changes . 



In the case where buttons have multiple bytes for the 
ID, the additional bytes are placed at the end of the 
packet and the length is changed accordingly. 

The Button status packets are used to supply button 
press/release information originating from the adjunct 
phone to the auxiliary PC. 
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Byte Description 

0 Header 

1 Packet Length 

2 Button Press (Raw) 

3 Raw ID byte #1 

4 [Raw ID byte #2] 



Value 
0x02 



3 + # of bytes 
in raw ID 



Byte 

0 

1 



Description 
Header 

Packet Length 



Button Release 
(Raw) 



Raw ID byte #1 
[Raw ID byte #2] 



Value 
0x02 



3 + # of bytes 
in raw ID 



Hook Switch Status 



The virtual phone contains a single hook switch which 
represents the state of the physical hook switch on the 
phone. A packet is sent when the state of the hook switch 
changes . 



Byte 
0 
1 
2 

Byte 
0 
1 
2 



Description 
Header 

Packet Length 
Hook Switch Up 

Description 
Header 

Packet Length 
Hook Switch Down 



Value 

0x02 

3 

0x54 

Value 

0x02 

3 

0x55 



Messages from the Auxiliary PC (Host) 
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All messages originating from the auxiliary PC 16 have 
a header value of 0x04. In many cases, the host 16 may 
emulate commands from the switch or the digital telephone. 
Any of the previously defined packets may be sent from the 
host. The header signs the virtual phone as to the source 
of the command so the appropriate action may be taken. 

Button Control and Status 

The virtual phone 20 is configured with a set of 
generic buttons used across all switches. These buttons 
(and associated lamps, if any), have fixed identifiers. 
Only the buttons with identifiers assigned to the virtual 
phone function with this command. 

The auxiliary PC 16 uses the button control and status 
packets to transmit button change requests to the virtual 
phone. The effect of these packets on the virtual phone 20 
is the same as if buttons were pressed on the adjunct phone 
directly. This protocol allows for auxiliary button 
press/release emulation. 

Regardless if button changes originate on the adjunct 
phone or the auxiliary PC 16, the virtual phone 20 
maintains the current button state. Whenever a button 
state changes, these same packets are used to transmit the 
new status to the auxiliary PC 16. 

System State 

When the host system is ready to receive messages from 
the virtual phone, it sends the enable command. This 
causes the virtual phone to send all virtual phone changes 
and system messages to the host via the host interface 
protocol. When the host is disabled, the virtual phone 
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still maintains the state phone state, it just blocks the 
information from being transmitted to the host. 



Byte Description Value 

0 Header 0x04 

1 Packet Length 4 

2 System State 0x90 

3 Level 

Disabled 0 

Enabled 1 



Pass Through Flags 

The host system has the ability to request certain 
types of messages to be passed or blocked between the 
switch and the digital telephone. It is the responsibility 
of the virtual phone to maintain these flags and send only 
the specified packets between the units. 

If the bit in the mask is set, the packet types are 
passed through. If cleared, they are blocked. 

Description Value 
Header 0x04 
Packet Length 4 
Hook Switch Up 0x91 
Flags 

Hook Switch 0x01 
from Set 

Buttons from 0x02 
Set 

Lamp updates 0x04 
from switch 
Display from 0x08 
Switch 

Ringer from 0x10 
Switch 
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Dial Command 

The host can request the virtual phone to dial a given 
string of digits. The virtual phone implements the button 
presses/releases and the necessary delays based on the 
parameters to the dial command. The dial string can 
contain any of the keypad buttons and the comma. The 
keypad buttons represent themselves and the commas 
represents a specified delay. 

The digit duration (byte 3) of the command represents 
the length in milliseconds that the key is to be held down. 
The inter-digit duration is the length between key presses. 
The pause duration is the length of the pause (comma) 
character. 

When the virtual phone completes the dialing, it sends 
a 3 byte version of this packet back to the host with only 
the header, length, and commands bytes 

Byte Description 

0 Header 

1 Packet Length 

2 Dial Command 

3 Digit Duration 

4 Inter-Digit 
duration 

5 Pause Duration 

6 Dial string 

Bearer Channel Direction 

Either the abstraction layer or the host system has the 
ability to direct the voice mux to their desired device. 



Value 
0x04 



6+# of digits 
in dial string 
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This device is typically either the adjunct digital phone, 
or an auxiliary unit. The virtual phone maintains the 
direction of the voice mux. In addition to voice, a number 
of additional channels can be controlled. This command is 
used to transfer mux direction status of all the bearer 
channels . 

If the bit in the mask is set, the mux is directed to 
the auxiliary unit. If cleared, the channel is directed to 
the adjunct digital telephone. 



Byte Description Value 

0 Header 0x04 

1 Packet Length 4 

2 Voice Mux 0x93 

3 Device Mask 



Voice 0x01 
Data 0x02 
Datal 0x02 
Data2 0x04 

Queries 

The auxiliary PC 16 can query the virtual phone 20 for 
current status at any time. This is done by sending a 
command symmetric to the receive command for each status 
type. These commands are the same as the receive commands 
with the exception of the upper most bit of the header 
byte. When this bit is high, the virtual phone interprets 
this as a query and automatically responds with the current 
status . 

For example, if the auxiliary PC 16 is requesting the 
ringer status, it sends the packet [81 04 20##] (where ## 
is irrelevant data) . The virtual phone 20 will respond by 



transmitting [01 04 20 ##] or [01 04 21] (where ## is valid 
data) back to the auxiliary PC. 

The valid query command IDs are: 

0x54 Query Hook Switch Status 

0x91 Query Pass Through Flags Status 

OxBO Query Switch Carrier Status 

OxBl Query Digital Phone Carrier Status 

0x10 Query Voice Status 

0x2 0 Query Ringer Status 

0x30 Query Lamp Status 

0x40 Query Display Status 

0x50 Query Button Status 

OxFO Query Switch Type 

OxFl Query Adjunct Phone Type 

0xF2 Query Current Active Phone 

0xF3 Query Last Touched Phone 

In connection with the foregoing description, Table I 
lists the data structures of virtual phone 20 and Table II 
lists various serial commands. 

Table I - Virtual Phone Structures 

typedef struct /^Virtual Phone Voice 

{ Structure*/ 

BYTE active; /*l=active 0=not active*/ 

BYTE unit; /*mask active unit UPV ???? */ 

BYTE volume; /*voice mute, low, high, etc 

*/ 

{VP_VOICE; 

typedef struct /^Virtual Phone Ringer 

Structure*/ 

BYTE active; /* 1-activeO-not active*/ 

BYTE cadence; /*list of current cadence 

type*/ 

BYTE tone; /*list of current tone type*/ 

{VP RINGER; 



typedef struct 

BYTE row; 

BYTE col; 

}VP_CURSOR: 
typedef struct 



/^virtual phone display- 
structure*/ 

/*Current row for this 
cursor*/ 

/*Current column for this 
cursor*/ 

/^Virtual Phone Display 
Structure*/ 



{VP_CURSOR; 

typedef struct 

BYTE grid[VPD_MAX 
ROWS] [VPD_MAXCOLS] 
BYTE cursor 
{VPD_MAXROWS} ; 
BYTE NumRows; 

BYTE NumColumns 

BYTE NumCursors; 

BYTE IsStable; 

BYTE IsClear; 

{VP_DI SPLAY; 
typedef struct 

BYTE deviceMask; 



/^Virtual Phone Display 

Structure*/ 

/*The display text*/ 

/^current cursors*/ 

/*Number of Rows on this 
page*/ 

/*Number of Columns on this 
page*/ 

/*Number of available 
cursors*/ 

/*True if the display has 
stablized* / 

/*True if the display is 
currently clear*/ 

/*Virtual Phone Button/Lamp 
Structure*/ 

/*mask showing which of next 4 
are valid*/ 



BYTE pressID; 

BYTE releaselD; 

BYTE lamplID; 

BYTE lamp2ID; 

BYTE buttons tate; 

BYTE lampl State; 

BYTE lamp2State; 
{VP_BUTTON; 
typedef struct 

{ 

VP_VOICE voice; 
VP_RINGER ringer; 
VP_DISPLAY display 
BYTE Hook Switch 
BYTE num_buttons; 

VP_BUTTON button 
[VP_MAXBUTS] ; 
BYTE StandAlone; 

BYTE SwitchType; 
BYTE DigSetType; 

BYTE Connections; 

BYTE ActivePhone; 

BYTE TouchedPhone; 

BYTE Carrier (2) ; 



/*ID of button press info*/ 
/*ID of button release info*/ 
/*ID of first lamp info*/ 
/*ID of second lamp info*/ 
/* state of button; l=down 0- 
up*/ 

/*state of first lamp*/ 
/*state of second lamp*/ 

/*Main Virtual Phone 
Structure*/ 

/*voice status*/ 
/*ringer status*/ 
/*LCD display status*/ 
/*Hook switch status*/ 
/*number of buttons actually 
in use*/ 

/*button/lamp status*/ 

/*0perate without Digital 
set*/ 

/*Type of switch connected*/ 
/*Type of configured digital 
SET, if any 

/*Which Phone Units are 
physically connected*/ 
/*Which Physical Phone Unit i 
active 

/*Which Physical Phone Unit 
was touched 

/*0=switch l=digital set*/ 



BYTE PassThroughFlags ; 
BYTE VoiceMux; 
VIRTUAL PHONE; 



/*event block flags*/ 
/*Bearer channel direction*/ 



Table II - Brief Host Command List 



Description 
Voice Enable 
Voice Disable 
Voice State 
Ringer Enable 
Ringer 
Disable 
Lamp 

(Generic) 
Lamp (Raw) 

Display 

Display Clear 
Button Press 
(Gen) 
Button 

Release (Gen) 
Button Press 
(Raw) 

Button 

Release (Raw) 
Hook Switch 
Up 



Header 

P 

P 

P 

P 

P 



P 

SHX 



Length 

05 

03 

05 

05 

03 



04+cou 
nt 

05+txt 
len 
03 
04 



03+cou 
nt 



Command Datal 
10 Unit 
11 
12 
20 
21 



Unit 
Cadence 



41 
50 



52 raw ID 

#1 

03+coun 53 raw 
t ID #1 

54 



41 ID 

#1 

col 



Volume 
Volume 



[raw 
ID 

#2. . .] 

[raw 
ID #2] 



[raw 
ID#2] 
text. 
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Description Header Length 



Hook Switch SHX 03 
Down 

System State HX 04 

Pass Through HX 04 
Flags 

Dial Command HX 09=dig 
its 

Bearer HX 04 
Channel Ctl 

Carrier state X 04 

- PBX 

Carrier State X 04 

- SET 

PBX type X 04 

SET type X 04 

Active Phone X 04 

Touched Phone X 04 

Physical X 04 
Cncts 



P-PPBX generated message 



S-SET generated message 

H-Host generated message 

X-Firmware system generated 
message 



Command Datal Data2 Data3 
55 



90 Level 

91 Flags 

92 see 
note 1 

93 Device 
mask 

B0 Level 

Bl Level 

F0 type 

Fl type 

F2 unit 

F3 unit 

F4 mask 



note 1 : parameters for dial 
command 

datal: digit duration (high 
byte) 

data2: digit duration (low 
byte) 

data3: inter-digit duration 
(high byte) 

date4 : inter-digit curation 
(low byte) 
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data5 



pause duration {high 



byte) 



data6 



pause duration (low 



byte) 

data7 : ? dial string 



The system of the present invention can be generalized 
in the form of the system of Fig. 5 including media control 
proxy 100, communication switch 102 and communication 
device or terminal 104. Switch 102 is analogous to PBX 12 
in Fig. 1, terminal 104 is analogous to phone 14 in Fig. 1 
and media control proxy 100 is a generalized form of the 
virtual phone 18 of Fig. 1. The Media Control Proxy (MCP) 
100 is used as a gateway between some communications 
switching system, i.e. switch 102, and some terminal, i.e. 
terminal 104. The main purpose of the MCP is to bridge any 
gap in the communication protocols between the server 
device (the switch) 102 and the client (the terminal 104) . 

Communication device 104 is any device which originates 
and/or receives a media including audio and visual, and 
device 104 can be a physical terminal or an emulation of a 
physical terminal in computer hardware including an 
application residing in a system. 

In the minimum configuration of Fig. 5, the MCP 100 
resides between the switch 102 and the terminal 104. 
Bearer channel data (voice, video, etc) is passed through 
by the MCP 100 on channels 110 and 112. The information on 
the control channels 114 and 116 is processed and converted 
to a protocol understood by the terminal 104. Depending on 
the type of terminal connected, this could be a proprietary 
protocol specific to the terminal, or it could be the MCP' - s 
standard protocol designed to communicate with a wide range 
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of devices. Control channel 116 also may be viewed as an 
application program interface (API) . 

The MCP 100 interprets the information it receives from 
the control channel 114 of the switch 102 and maintains the 
state of the terminal 104 as defined by the switch 102. As 
far as the switch 102 is concerned, the MCP 100 is the 
terminal 104. The MCP 100 also transmits data on the 
control channel 114 to the switch 102. It does this in the 
protocols native to the switch 102. The switch 102 
interprets any messages coming from the MCP 100 as those 
coming from the terminal 104. 

The MCP 100 can be configured to function in many 
different ways. The main point is that it has the ability 
to communicate with not only the native terminal for the 
switch, but that it can communicate with an unlimited 
selection of terminals or communications devices. The 
fixed (and sometimes proprietary) control protocol used in 
the original connection between the switch and native 
terminal is converted to whatever communications method is 
necessary to support any given terminal. 

The type of terminal that may be connected to the MCP 
100 is so flexible that the type of medium in which the 
date and control channels reside is also limitless. A 
direct proprietary connection is possible, as is a 
connection over a computer bus. It is also possible to 
route data and control channel information across new or 
existing networks. Means of wireless communications is 
supported. In fact, this system is set up to be 
configurable to operate with any terminal in whichever 
transport is desired. The MCP 100 handles the data 
preparation for any such configuration. 
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It is therefore apparent that the present invention 
accomplishes its intended objects. A telephone 
communication system is provided which converts proprietary 
PBX or external application protocols into a common format 
and thus functions as a protocol interpreter between 
proprietary switching system protocols and the protocols of 
various applications. The virtual phone generic interface 
of the present invention is configurable and works 
independently of a specific type of integration and 
provides a common interface between any of the digital 
phone switches and any number of end devices. Changes in 
the virtual phone interface are communicated to an external 
processor which, in turn, can command changes in the 
virtual phone interface. 

While an embodiment of the present invention has been 
described in detail, that is done for purposes of 
illustration, not limitation. 



What is claimed is: 



